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(54) Method and apparatus for conducting crypto-ignition processes between thin client devices 
and server devices over data networks 



(57) The present invention relates to a method for 
establishing a secure communication channel between 
thin devices (302. 304, 306) and a server computer (37) 
over an insecure data network (102). A pair of public 
values is exchanged between )the thin device and the 
server computer over the data network, with each side 
generating its own secret key from a self-generated pri- 
vate value along with the received counterpart's public 



value according to a commonly used key agreement 
protocol, such as the Diffie-Hellman key agreement pro- 
tocol. To ensure that the generated secret keys are iden- 
tical on both sides, a verification process is followed by 
exchanging a message encrypted by one of two gener- 
ated secret keys. The secret keys are proved to be iden- 
tical and secret when the encrypted message is suc- 
cessfully decrypted by the other secret key. 
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Description 

BACKGROUND OF THE INVENTION 
Field of Invention 

[0001] The invention relates to secure and authenti- 
cated data communications between client computers 
and server computers, and more particularly relates to 
methods and apparatus for conducting crypto-ignition 
processes between two-way interactive communication 
devices and server computers over data networks that 
may be wireless network or the Internet; wherein the 
two-way interactive communication devices, such as 
mobile devices, cellular phones, landline phones and In- 
ternet appliance controllers, have generally limited com- 
puting resources such as computing power, memory 
and graphical display capability. 

Description of the Related Art 

[0002] A fast-growing trend on the Internet is electron- 
ic commerce. The electronic commerce is an integrative 
concept designed to draw together a wide range of busi- 
ness support services, trading support systems for com- 
modities, products, customized products and custom- 
built goods and services; ordering and logistic support 
systems; settlement support systems; and manage- 
ment information and statistical reporting systems, all 
via the global Internet. It is well known, however, that 
the Internet is a wide open, public and international net- 
work of interconnected computers and electronic devic- 
es around the world. To transact business over the In- 
ternet, companies or individuals must have an efficient, 
reliable and secured manner to conduct private commu- 
nications among themselves. There have been many ef- 
forts in progress aimed at protecting the proprietary in- 
formation travelling across the Internet, mostly for com- 
puter devices in landline networks. 
[0003] One of the ongoing efforts is to use crypto- 
graphic techniques to secure a private communication 
session between a client computer and a server com- 
puter. The cryptographic techniques provide a way to 
transmit information across an insecure communication 
channel without disclosing the contents of the informa- 
tion to anyone eavesdropping on the communication 
channel. Using an encryption process in a cryptographic 
technique, one party can protect the contents of the data 
in transit from access by unauthorized third party while 
the intended party can read the data using a corre- 
sponding decryption process. Encryption is a process 
of transforming a set of data into some unreadable "en- 
crypted" form. The purpose thereof is to ensure privacy 
by keeping the actual contents of the information hidden 
from unintended recipients such as eavesdroppers that 
might access the encrypted data. Decryption is the re- 
verse process of the encryption. Decryption is a process 
of transforming encrypted data back into some intelligi- 



ble form such that the actual contents can be accessed. 
Both encryption and decryption require the use of some 
secret information, usually referred to as a "key." De- 
pending on the type of encryption mechanism used, the 

5 same key might be used for both encryption and decryp- 
tion, while for other mechanisms, the keys used for en- 
cryption and decryption might be different. 
[0004] Traditional cryptographic techniques are 
based on the sender and receiver of a message knowing 

10 and using the same secret key: the sender uses the se- 
cret key to encrypt the message, and the receiver uses 
the same key, often referred to as the secret key, to de- 
crypt the message. Thus, to keep the communication 
channel secure, no users other than the sender or re- 

is ceiver should be allowed access to the secret key. This 
method is known as secret-key or symmetric private-key 
cryptography. It should be noted that private-key cryp- 
tography requires a secure channel to transfer the pri- 
vate key between the sender and the receiver. 

20 [0005] A relatively new concept of encryption known 
as public-key cryptography uses two different keys. In 
the two key public- key cryptography systems, each user 
has two keys: a public key that is published and a private 
key that is kept secret. To encrypt a message to a public 

2S key recipient user, a sender encrypts a message using 
the recipient's public key. The recipient then decrypts 
the message using his private key. Thus, secure com- 
munication can commence without having to transfer a 
secret key across a secure channel. 

30 [0006] Thus, the primary advantage of the public-key 
cryptography is that private keys never need to be trans- 
mitted or revealed to anyone. In the secret-key cryptog- 
raphy, by contrast, the secret keys or information to gen- 
erate them must be transmitted (either manually or 

35 through a secure communication channel). However, 
one known disadvantage of using the public-key cryp- 
tography for encryption is the encryption speed. Specif- 
ically, there are popular private-key encryption methods 
that are significantly faster than any currently available 

40 public-key encryption method. Thus, encryption speed 
becomes a very important factor in considering the pri- 
vate-key cryptography versus the public-key cryptogra- 
phy when a cryptographic technique is used in a secure 
communication session involving a thin client device 

45 with limited computing resources. The thin client device 
referred to is considered to be a two-way interactive 
communication device such as a mobile computing de- 
vice, cellular phone : landline phone or an Internet appli- 
ance controller. A thin client device is generally de- 

50 signed small in size, light in weight, low in power con- 
sumption and as economically and portably as possible. 
Such thin client designs often result in very limited com- 
puting resources, for example, the computing power 
therein is, perhaps, typically equivalent to less than one 

5 5 percent of what is provided in a typical desktop or port- 
able computer, and the memory capacity thereof is gen- 
erally less than 250 kilobytes. In addition, the commu- 
nication between the thin client and a landline server 
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computer is often via a wireless network that is charac- 
terized with low bandwidth, the airtime thereof is expen- 
sively measured. Therefore the private-key cryptogra- 
phy is often used in the communication session between 
thin clients and landline computers to accommodate the 
speed requirement. 

[0007] The distribution of the private encryption keys 
between two trusted communicating devices is called 
the crypto-ignition process. Manual delivery of private 
encryption keys in a secret manner can be used as one 
of the crypto-ignition methods, but the cost can be con- 
siderable when there are hundreds, perhaps thousands 
of the thin clients in communication with one landline 
server computer. Further the human errors and trust as- 
sociated with this approach make it infeasible to use in 
reality. Therefore, there is a great need for a generic 
crypto-ignition process that allows automatic deliveries 
of the private keys between each of the thin clients re- 
spectively with the landline server computer. 
[0008] Although key agreement protocols may be 
used alone for the two communicating parties to agree 
on secret keys on each side, the authentication thereof 
is not provided. Use of the key agreement protocols 
does not guarantee that the keys agreed upon are not 
attacked in any manner. Lack of the authentication in 
such schemes makes those agreed keys not strong 
enough to sustain in security for a long term. There may 
be solutions to modify those schemes for having the au- 
thentication in place, but it generally requires some se- 
cret information to be pre-loaded into the communicat- 
ing devices, hence resulting in more transactions be- 
tween a thin client device and a server computer. The 
additional transactions may further demand a significant 
increase in computing power and memory in the thin de- 
vices and increase the. latency of information arrival from 
a server computer, which is generally undesirable. 
Th us, there is a further need for a crypto-ignition process 
that conducts the crypto-ignition process between two 
communicating devices using minimum computing 
power and memory therein 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0009] These and other features, aspects, and advan- 
tages of the present invention will become better under- 
stood with regard to the following description, appended 
claims, and accompanying drawings where: 

Figure 1 shows a schematic representation of a mo- 
bile data network in which the present invention 
may be practised; 

Figure 2 shows a typical example of a mobile device 
that includes the linked and compiled processes of 
the present invention; 

Figure 3 illustrates the architecture of the present 
invention; 

Figure 4 demonstrates interactions between a client 
module and a server module through a pair of re- 



spective UDP interfaces when the crypto-ignition 
process is being conducted between a client device 
and a server device; and 

Figure 5A and Fig 5B depict a data flowchart repre- 
s senting the crypto-ignition process being conducted 
between a client device and a server device. 

DETAILED DESCRIPTION OF THE INVENTION 

10 Notation and Nomenclature 

[0010] In the following detailed description of the 
present invention, numerous specific details are set 
forth in order to provide a through understanding of the 

is present invention. However, it will become obvious to 
those skilled in the art that the present invention may be 
practised without these specific details. In other instanc- 
es, well known methods, procedures, components, and 
circuitry have not been described in )detail to avoid ob- 

20 scuring aspects of the present invention. 

[0011] The detailed description of the present inven- 
tion in the following are presented largely in terms of 
procedures, steps, logic blocks, processing, and other 
symbolic representations that resemble of data 

2S processing devices coupled to networks. These process 
descriptions and representations are the means used 
by those experienced or skilled in the art to most effec- 
tively convey the substance of their work to others 
skilled in the art. The present invention is a method and 

30 apparatus for conducting a crypto-ignition process be- 
tween a two- way interactive communication device and 
a server device over a data network. The method along 
with the architecture to be described in detail below is a 
self -consistent sequence of processes or steps leading 

35 to a desired result. These steps or processes are those 
requiring physical manipulations ol physical quantities. 
Usually, though not necessarily, these quantities may 
take the form of electrical signals capable of being 
stored, transferred, combined, compared, displayed 

40 and otherwise manipulated in a computer system or 
electronic computing devices. It proves convenient at 
times, principally for reasons of common usage, to refer 
to these signals as bits, values, elements, symbols, op- 
erations, messages, terms, numbers, or the like. It 

45 should be borne in mind that all of these similar terms 
are to be associated with the appropriate physical quan- 
tities and are merely convenient labels applied to these 
quantities. Unless specifically stated otherwise as ap- 
parent from the following description, it is appreciated 

50 that throughout the present invention, discussions uti- 
lizing terms such as "processing" or "computing" or "ver- 
ifying" or "displaying" or the like, refer to the actions and 
processes of a computing device that manipulates and 
transforms data represented as physical quantities with- 

55 in the computing device's registers and memories into 
other data similarly represented as physical quantities 
within the computing device or other electronic devices. 
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Introduction to Diffie-Hellman key agreement protocol 

[001 2] The Diffie-Hellman key agreement protocol, al- 
so called exponential key agreement, allows two users 
to exchange a secret key over an insecure medium with- 
out any prior secrets. The protocol has two system pa- 
rameters p and g. Both pand g public and may be used 
by all the users in a system. Parameter p is a prime ) 
number and parameter g (usually called a generator) is 
an integer less than p, which is capable of generating 
every element from 1 to p- 1 when multiplied by itself a 
certain number of times, modulo the prime p. 
(0013] Suppose a party A and a party B wants to 
agree on a shared secret key using the Diffie-Hellman 
key agreement protocol. They proceed as follows: First, 
party A generates a random private value a and party B 
generates a random private value b. Then they derive 
their public values using parameters p and g and their 
private values. Party A's public value is g* mod p and 
Party B's public value is mod p. They then exchange 
then public values. Finally, Party A computes k ab = (g b ) a 
mod p. and party B computes /c to = (g 3 )* mod p. Since 
k at> - k^ - k, party A and party B now have a shared 
secret key k. The protocol depends on the discrete log- 
arithm problem for its security. It assumes that it is com- 
putationally infeasible to calculate the shared secret key 
Ac = g 3b mod p given the two public values g 3 mod p and 
g b mod p when the prime p is sufficiently large. 
[0014] The Diffie-Hellman key exchange is vulnerable 
toa middleman attack. In this attack, an opponent, Party 
X. intercepts Party A's public value and sends his own 
public value to Party B. When Party B transmits his pub- 
lic value, Party X substitutes it with his own and sends 
it to Party A. Party X and Party A thus agree on one 
shared key and Party X and Party B agree on another 
shared key. After this exchange, Party X simply decrypts 
any messages sent out by Party A or Party B, and then 
reads and possibly modifies them before re- encrypting 
with the appropriate key and transmitting them to the 
correct party This vulnerability is due to the fact that Dif- 
fie-Hellman key exchange does not authenticate the 
participants. 

[0015] To overcome the middleman attack, the au- 
thenticated Diffie-Hellman key agreement was intro- 
duced. The immunity is achieved by allowing the two 
parties to authenticate themselves to each other by the 
use of digital signatures. The basic idea is as follows: 
[0016] Before the exchange protocol, the two parties 
Party A and Party B each possess a public/private key 
pair and a certificate for the public key. During the ex- 
change protocol, Party A computes a signature on cer- 
tain messages using her private key and sends Party B 
the public value g a mod p together with her signature 
and her public-key certificate. Party B also computes a 
signature using his private key and sends Party A the 
public value g 3 mod p together with her signature and 
her public-key certificate. Even though Party X is still 
able to intercept messages between Party A and Party 



B, she cannot forge signatures without Party A's private 
key and Party B's private key. Hence, the enhanced pro- 
tocol defeats the middleman attack. 

s The Preferred Embodiment 

[0017] According to the principles of the present in- 
vention, a crypto-ignition process to deliver an identical 
secret key to two communicating parties is conducted 
between a thin client device and a server computer over 
a data network. The thin client device generally has lim- 
ited computing power and limited working memory. The 
server computer may communicate with a plurality of 
such thin client devices. To ensure the security of the 
secret key on both sides and reduce traffic in the net- 
work, only a pair of public values is exchanged between 
the thin client device and the server computer over the 
data network. Each side generates its own secret key 
from a self -generated private value along with the re- 
ceived counterpart's public value according to a com- 
monly used key agreement protocol, such as the Diffie- 
Hellman key agreement protocol. To ensure that the 
generated secret keys are identical on both sides, veri- 
fication processes are followed by exchanging a mes- 
sage encrypted by the generated client-side secret key 
and a manual verification of signatures generated from 
the two generated secret keys. The secret keys are 
proved to be identical when the encrypted message is 
successfully decrypted by the other secret key and se- 
cure when the signatures are verified. To reduce net- 
work traffic, the verification process is piggybacked with 
a session request from the thin device to establish a se- 
cure and authentic communication session with the 
server computer. The present invention enables the au- 
tomatic delivery of the secret keys, without requiring sig- 
nificant computing power and working memory, be- 
tween each of the thin clients respectively with the serv- 
er computer. 

[0018] Referring now to the drawings, in which like nu- 
merals refer to like parts throughout the several views. 
Figure 1 shows a schematic representation of a data 
network 100 in which the present invention may be prac- 
tised. The data network 100 comprises an aimet 102 
that is generally called wireless network and a landnet 
104 that is generally a landline network, each acting as 
a communication medium for data transmission there- 
through. The airnet 102, in which the data transmission 
is via the air, is sometimes referred to as a carrier net- 
work because each airnet is controlled and operated by 
a carrier, for example AT&T and GTE. Each carrier my 
have its own communication scheme, such as CDPD, 
CDMA, GSM and TDMA for the aimet 1 02. The landnet 
104, used interchangeably herein, may be the global In- 
ternet, an Intranet or other private networks. Referenced 
by 106 is of the mobile devices that can be a mobile 
device, a cellular phone, a landline telephone or an In- 
ternet appliance controller, capable of communicating 
with the airnet 102 via an antenna 108. It is generally 
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understood that the airnet 102 communicates simulta- 
neously with a plurality of two-way communication de- 
vices, of which only one example mobile device 106 is 
shown in Figure 1 . Similarly, connected to the Internet 
104 are a plurality of desktop PCs 110 and a plurality of 
server computers 112, though only one representative 
respectively shown in Figure 1 . The PC 110, as shown 
in the figure, may be a personal computer SPL 300 from 
NEC Technologies Inc. The PC 110 may execute a Hy- 
perText Markup Language (HTML) Web browser such 
as Netscape Navigator or Microsoft Internet Explorer to 
access information on the Internet 104 using HyperText 
Transport Protocol (HTTP). For example, the PC 110 
may access HTML information stored in the web server 
112 that may be a workstation from Sun Microsystems 
Inc. It is understood to those skilled in the art that the 
PC 110 can store accessible information therein so as 
to become a web server as well. 
[0019] Between the Internet 104 and the airnet 102 
there is a link server or proxy server computer 114 for 
performing data communication therebetween. The 
proxy server computer 114, also referred to as link serv- 
er or gateway server computer, may be a workstation or 
a personal computer that performs mapping or transla- 
tion functions. For example, the proxy server computer 
114 may map information from one protocol to another, 
such that the mobile device 106 can be in communica- 
tion with any dne of the servers 112 or the PCs 110, re- 
spectively. 

[0020] One communication protocol used on the In- 
ternet 1 04 is the well known HyperText Transfer Protocol 
(HTTP) or HTTPS, a secure version of HTTP. HTTP us- 
es the well known Transport Control Protocol (TCP) to 
build a connection for carrying HyperText Markup Lan- 
guage (HTML) information. For example, an HTML Web 
browser in the proxy server 114 may access HTML in- 
formation stored in the Web server 112. In the embodi- 
ment of Figure 1 , the communication protocol between 
the mobile device 1 06 and the proxy server 1 1 4 via the 
airnet 102 is the Handheld Device Transport Protocol 
(HDTP) or Secure Uplink Gateway Protocol (SUGP) 
which preferably runs on User Datagram Protocol 
(UDP). The HDTP controls the connection of a small 
Web browser in the mobile device 1 06 to the proxy serv- 
er 114. In the embodiment of Figure 1, the browser in 
the mobile device 106 may be a Handheld Device 
Markup Language (HDML) browser. The Handheld De- 
vice Markup Language (HDML) is similar to HTML in 
that it is a tag based document language and comprises 
a set of commands or statements that specify how in- 
formation is to be displayed on a display device. HDML 
is a specific markup language designed to specify in a 
"card" how information should be displayed on a small 
screen of the mobile device 106. Normally a number of 
cards are grouped into a deck that is the smallest unit 
of HDML information that can be exchanged between 
the mobile device 106 and the proxy server 114. More 
description on the HDML cards and deck will be de- 



8 

scribed below wherever appropriate. The specifications 
of HDTP. entitled "HDTP Specification 0 and HDML, en- 
titled "HDML 2.0 Language Reference" are enclosed 
and incorporated herein by reference in their entirety. 

s [0021] The HDTP is a session-level protocol that re- 
sembles the HTTP but without incurring the overhead 
thereof and is highly optimized for use in thin devices 
that have significantly less computing power and mem- 
ory. Further it is understood to those skilled in the art 

io that the User Datagram Protocol (UDP) does not require 
a connection to be established between a client device 
and a server device before information can be ex- 
changed, which eliminates the need of exchanging a 
large number of packets during a session creation be- 

15 tween a client and a server. Exchanging a very small 
number of packets during a transaction is one of the de- 
sired features for a mobile device with very limited com- 
puting power and memory to effectively interact with a 
landline device. 

20 [0022] Referring now to Figure 2, there is showed a 
block diagram of a typical GSM digital mobile phone 1 20 
that can be used in Figure 1 to practice the present in- 
vention. Each of the hardware components in the mobile 
phone 1 20 is known to those skilled in the art and so the 

2S hardware components are not to be described in detail 
herein. With the screen 116 and the keypad 118, a user 
of the phone 120 can interactively communicate with a 
server device (not shown in Figure 2) over the data net- 
work. According to one embodiment of the present in- 

30 vention, compiled and linked processes of the present 
invention are stored in ROM 1 22 as a client module 1 24 
and support module 1 26. Upon activation of a predeter- 
mined key sequence utilizing the keypad 118, a physical 
layer processor or microcontroller 128 initiates a com- 

3S munication session request to a server device (not 
shown) using the client module 124 in the ROM 122. 
Upon establishing the communication session, the 
phone 120 typically receives a single HDML deck from 
the server device and stores the deck as cached in RAM 

40 1 34. An HDML deck or deck is the smallest unit of HDML 
information that can be exchanged between a thin client 
device and a server device. Each deck has a unique ad- 
dress identifier such as a URL and includes one or more 
cards. A card includes the information required to gen- 

45 erate a screen display on the display screen 1 1 6. Thus, 
a deck is simply a group of screen displays. The number 
of cards in a card deck is selected to facilitate efficient 
use of the resources in the mobile device and in the air- 
net network. A display driver 1 30 receives and interprets 

50 information from the deck in the RAMI 34 and causes 
the screen 116 to display the information accordingly. 
The keypad driver 132 receives signals representing 
what buttons or keys in the keypad 118 are depressed 
and converts the signals to a representation understood 

ss by the microcontroller 1 28 that in turn responds, for ex- 
ample, by activating a respective card in the deck or a 
new link to the server for a new deck if necessary de- 
pending on what choice is made through the phone key- 
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pad 118. 

[0023] Referring nowto Figure 3, there is depicted the 
architecture of the present invention. Referenced by 
302, 304 and 306 are three representatives of a plurality 
of the mobile devices coupled to the airnet 1 02, similarly 
referenced by 310, 312 and 314 are three representa- 
tives of a plurality of landline devices coupled to the 
landnet 104. The link server device 370 couples the air- 
net 102 to the landnet 1 04, therefore any mobile devices 
can communicate with the landline devices via the airnet 
102 through the link server 370 to the landnet 104. It is 
understood to those skilled in the art that the mobile de- 
vices may be the one shown in Figure 2. To facilitate the 
description of the present invention, the internal block 
diagrams of the mobile device 302 and the link server 
370 are respectively illustrated. Other processes and 
hardware are known to those skilled in the art and are 
not illustrated in detail in the figure for clarity. 
[0024] Each of the mobile devices, such as the one 
302, is assigned to a device ID 316. The device ID 316 
can be a phone number of the device or a combination 
of an IP address and a port number, for example: 
204.163.165.132:01905 where 204.163.165.132 is the 
IP address and 01905 is the port number. The device 
ID 316 is further associated with a subscriber ID 318 
authorized by a carrier in the link server 370 as part of 
the procedures to activate a subscriber account 320 for 
the mobile device 302. The subscriber ID 318 may take 
the form of, for example, 861234567-10900 _pn. mobile. 
att.net by AT&T Wireless Service, it is a unique identifi- 
cation to the mobile device 302. In other words, each of 
the mobile devices 302, 304 and 306 has a unique de- 
vice ID that corresponds to a respective user account in 
the link server device 370. The following description is 
focussed on the mobile device 302 and the associated 
account 320, it will be appreciated by those skilled in the 
art that the description is equally applied to a plurality of 
the mobile devices in communication simultaneously 
with the link server 370. 

[0025] The subscriber account 320, indexed by the 
device ID 316, is a data structure comprising the sub- 
scriber information such as a subscriber number 318, 
user info 322, key state 321 and a signature 325. The 
user info 322 may include the account configuration and 
other account related information, such as usemame, a 
URL, a device version and date. The key state 321 in- 
dicates the state of a shared secret key. The signature 
325 is a result generated from the shared secret key by 
using the symmetric encryption algorithms such as 
RC5. When the account is newly established; the key 
state 321 is set to "Exchange" and no signature is avail- 
able in the signature 325. More on the key state and 
signature will be described below. The URL of the ac- 
count may take the form of, for example, http://www.att. 
com/Pocketnet, which indicates that the airnet 1 02 is op- 
erated by AT&T wireless service. It can be appreciated 
that when the link server 370 provides services to a 
number of mobile devices, there will be the same 



number of such accounts, preferably kept in a database 
server 328, each of the accounts designated respective- 
ly to one of the mobile devices. 
[0026] It should be noted that the database server 328 

5 is not necessary in the present invention. The database 
server 328, providing means for storing the accounts, 
may be a separate computer or a memory storage in the 
link server 370. It is further understood that the link serv- 
er 370 is one of the landline devices, any of the landline 

10 devices can function as the link server 370 and be either 
a client device or a server device depending on what 
applications being used in the devices. To minimize pos- 
sible ambiguities in the following description, the mobile 
device shall be referred to as the client device or thin 

15 client device hereafter and the link server 370 shall be 
simply referred to as the server device. 
[0027] As described above, the compiled and linked 
processes of the present invention are stored in a mem- 
ory as the client module 332 in the client device 302. 

20 Similarly a corresponding compiled and linked process- 
es of the present invention are loaded in a memory as 
the server module 320 in the server device 370. The 
communication between the client device 302 and the 
server device 370 is conducted between the client mod- 

2S ule 332 and the server module 320 via a pair of User 
Datagram Protocol (UDP) interfaces 336 and 324. 
[0028] When a user of the client device 302 presses 
a predetermined key to interact with the server device 
370, for example, to fetch price information on a partic- 

30 ular stock, the client module 332 sends a corresponding 
request in form of the HDML deck to the UDP interface 
336 which further transmits the request to the counter- 
part UDP interface 324 in the server device 370. The 
request is processed by the link server 370 and may re- 

35 suit in a further connection to another server device 310 
or 31 2 on the Internet if the link server 370 does not host 
the stock price information. Nevertheless the stock price 
information is eventually packed into one or more cards 
in an HDML deck at 340. The HDML deck is sent back 

40 by the server module 320 to the client 302 through the 
UDP interlaces 336 and 324. With the received HDML 
deck, preferably cached in a RAM, the client module dis- 
plays the card or cards on the display screen of the client 
device 302. If the information exchanging between the 

45 client device 302 and the link server device 370 needs 
to be secret, then a secure communication using en- 
cryption/decryption technique must be established on 
both sides before any secret information can be ex- 
changed. 

so [0029] Referring now to Figure 4, there is demonstrat- 
ed interactions between the client module 332 and the 
server module 320 through the pair of respective UDP 
interfaces when thecrypto-ignition process is being con- 
ducted between the client device 302 and the link server 

55 device 370. When the client device 302 is instructed by 
the user thereof to interact with the link server device 
370, the client module 332 sends a session request sig- 
nal 402 (SR 402) to the server module 320 to create a 
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communication session between the client device 302 
and the link server device 370. The signal components 
in SR 402 depend on the status of the client device 302 
and generally comprise: 

- sessionID - an identifier identifying all requests from 
the client device 302 to the link server device 370; 
In the case of requesting a session to be created, 
sessionID is always assigned to 0; 
cipher - a two-byte number representing the choice 
of the encryption the client is currently using as 
there are a number of encryption schemes available 
in a communication protocol; 
version - a one byte number representing the HDTP 
protocol version in use, used to determine the un- 
derlying format of the communication protocol such 
as PDU; 

type - either a fixed five-byte number representing 
what device the client is, e.g. 2PCSI means the cli- 
ent is a PCSI phone version 2. 
devicelD - a variable up to 255-byte, representing 
the device identifier or the client identifier; 
header - up to 32767 bytes, comprising token/value 
pairs that apply to an entire session and may be au- 
tomatically applied to subsequent service requests 
or session specific parameters, therefor the header 
is generally cached in the server till the current ses- 
sion completes; and 

C-nonce - a client nonce represented with a non- 
repeatable number, usually 2 bytes, usedforthe cli- 
ent to conduct a following server authentication. 
C-nonceModified - a modified version of the client 
nonce, used for the server to conduct a nonce ver- 
ification in the following client authentication. 

[0030] To be more specific, the cipher in SR 402 in- 
cludes an identifier to a particular encryption algorithm 
and associated parameters thereof, namely the first 
byte in the cipher represents the identifier to a combina- 
tion of the encryption algorithm, the key size (e.g. 128- 
bit for US or 40-bit for foreign countries) and content of 
a security attachment thereto and the second byte in the 
cipher indicates the additional parameters related to the 
first byte. For example, value 1 in the first byte indicates 
that the encryption algorithm is a block cipher RC5, the 
key size thereof is 1 28 bit, a two byte check-sum therein 
is used as Message Authentication Code (MAC), no In- 
itialization Vector (IV) for block ciphers therefor is trans- 
mitted over the network, and padding bytes are added 
if necessary. Information about block ciphers and the 
various available encryption algorithms can be found in 
almost any book on contemporary cryptography or M.J. 
B. Robshaw, "Block Ciphers", Technical Report TR-601 , 
version. 2.0, RSA Laboratories, 100 Marine Parkway, 
Redwood City CA 94065-1031, August 1995. It can be 
further appreciated that the identifier in the cipher may 
be assigned to a unique value to identify a non-secure 
session if so desired. The C-nonce is a non-repeatable 



number initially and randomly generated in the client 
and the modified version thereof, C-nonceModified, is 
generated from the C-nonce through a operational rela- 
tionship. 0 For example, the C-nonceModified may be 
s generated using an Exclusive-OR relationship^) that 
may be expressed as follows: 

C-nonceModified = 2-byte-number e C-nonce. 

[0031] Both C-nonce and C-nonceModified are en- 
crypted by the cipher using a secret encryption key pos- 
sessed by the client device 302. The purpose of the C- 
nonceModified is to provide the server that receives the 
SR with means for ensuring that C-nonce is correctly 
decrypted and validated by examining the C-nonce and 
its relationship with the C- nonceModified. If the server 
device 370 has a valid secret key that is identical to the 
one in the client device 302, the encrypted C-nonce and 
C-nonceModified should be decrypted by the valid se- 
cret key and the relationship therebetween remains the 
same. In other words, a SR message 402 may be ex- 
pressed as follows: 

SR = {session ID, cipher, version, type, device ID, 
header, Encry[C-nonce, C-nonceModified]}; 

where Encry[ ] means that the parameters or contents 
in the bracket are encrypted accordingly. 
[0032] The server module 320 attempts to decrypt En- 
cry[C-nonce, C-nonceModified] when SR 402 is re- 
ceived. From the decrypting process, the server device 
370 can determine the state of the secret keys on both 
sides. There are four possible secret key stales, "Valid", 
"Verify", "Exchange" and "Force". The "Valid" key state, 
resulting from a successful decryption of the encrypted 
message in SR 402, means that the pair of the secret 
keys on both sides are identical, hence each, the client 
device 302 or the server device 370, possesses a 
shared secret key (SSK) and a newcrypto-ignition proc- 
ess is not needed. The "Verify" state indicates that the 
SSK generated by a new crypto-ignition process has not 
been verified, it must be followed by a verification proc- 
ess. The "Exchange" key state indicates that the crypto 
ignition process is allowed at any time at a request by 
the client device 302, this is usually the case when the 
user account of the client device 302 is newly estab- 
lished. The "Force" key state indicates that the crypto- 
ignition process must be conducted before any new ses- 
sion can be created. The "Force" state may be entered 
as a result from a complete failure of decrypting the en- 
crypted message in SR 402. 

[0033] When the client device 302 is newly activated 
and powered on, the key state is automatically set to 
"Exchange" by default. The key request 406 is then sent 
to the server device 370 for a crypto-ignition process to 
start. The C-nonce and C-nonceModified in SR are not 
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encrypted, which results in errors when the server mod- 
ule 320 tries to decrypt Encry[C-nonce, C-nonce Modi- 
fied]. The server sends to the client 332 a Request Re- 
sponse 404 with the errors indicating that the commu- 
nication session can not be established without first con- s 
ducting the crypto-ignition process. 
[0034] The crypto-ignition process is always initiated 
by sending the key request 406 by the client device 302 
to the server device 370 if the key state is either Ex- 
change or Force. Nevertheless the process can also be 10 
started if the server device 370 initiates and the client 
device 302 agrees to proceed with the crypto-ignition 
process. This may occur when the current SSK expires. 
A SSK has limited lifetimes for a number of reasons. The 
most important reason is protection against what is 15 
called cryptanalysis. Each time the SKK key is used, it 
generates a number of ciphertexts. Using a key repeti- 
tively allows an attacker to build up a store of ciphertexts 
(and possibly plain texts) which may prove sufficient for 
a successful cryptanalysis of the key value. Other in- 20 
stances of the server initiated cyptocrypto-ignition proc- 
ess include mismatch between two SSKs on each side. 
The crypto-ignition process in the client device may be 
initiated by a session request response (SRR) 404 sent 
from the server module 320 to the'client module 322. 25 
SRR 404 comprises a key error message due to the ex- 
piration or mismatch of the SSKs on both sides. 
[0035] Before the client device 302 sends out the key 
request 406, the client module 332 generates a private 
value, referred to as the client private value, from a ran- 30 
dom number. A random number generator normally 
takes in a random number seed. It is understood to 
those skilled in the art that there are many random 
number generators available, such as the rand( ) func- 
tion available in standard C libraries. Furthermore, there as 
are many ways to get a random number seed such as 
examining a noise signal off the antenna, a hard coded- 
in source or provided by the client device manufacturer. 
With the random number seed, the client private value 
is then generated by the random number generator that 40 
may be a one-way hash function as its core engine. The 
one-way means that it is significantly easier to perform 
in one direction (the forward direction) than in the oppo- 
site direction (the inverse direction), which makes it un- 
likely to derive the random number seed from the ran- 45 
dom number generated. One example of the hash func- 
tions is to multiply a value itself a certain number of times 
and followed by a modulo operation. The client private 
value generally takes the form of a 16 byte long bjnary 
number. The client private value is so generated and so 
sufficiently large enough that it is unlikely to statistically 
duplicate the client private value based on trying all pos- 
sible random numbers. The generated client private val- 
ue is then used as an input to generate a public value, 
referred to as the client public value according to a key 55 
agreement protocol, such as the Diffie-Hellman key 
agreement protocol. The client public value is often a 96 
byte binary number for communications within US and 



a 64 byte binary number for communications outside 
US. According to one embodiment of the present inven- 
tion, a library called LI BDH is used to generate the client 
public value. The LI BDH is part of the product, called 
BSAFE, that is a general purpose and low-level crypto- 
graphic toolkit from RSA Laboratories having a business 
of 100 Marine Parkway, Suite 500, Redwood City, CA 
94065 1031. The engine comprises the Diffie-Hellman 
key agreement protocol, the ciphers and hashing func- 
tions. The client private value is retained within the client 
device 302 and the client public value is to be transmit- 
ted to the server device 370. The client module then 
sends a key request signal 406 to the server device 370. 
The key request 406 comprises the device ID 316 of the 
client device 302 and the generated client public value. 
[0036] The crypto-ignition process in the server de- 
vice 370 starts when receiving the key request 406 from 
the client device 302. As described above, the key re- 
quest 406 from the client device 302 may result from the 
error message sent from the server device 370 or a 
manual request by the user of the client device. Upon 
receiving the key request 406 from the client device 302, 
the server device 370 proceeds with the crypto-ignition 
process, after performing a series of authentication 
processes based on the device ID 326, by generating a 
private value, referred to as the server private value. 
Similar to the client private and public values, the server 
private value is generated from a random number seed 
that can be produced from a noise source such as a 
noisy diode or traffic events in the server device 370. 
The private value is also a 16 byte long binary number 
With the server private value as an input, a public value, 
or server public value, also a 96 or 64 byte binary 
number, is generated therefrom using the library LIBDH. 
[0037] As described above, the Diffie-Hellman key 
agreement protocol requires two numbers to generate 
a secret key. The server module 320 uses the client pub- 
lic value in the received key request signal 406 along 
with the self-generated server private value to generate 
a server- side secret key based on the Diffie-Hellman 
key agreement protocol provided in LI BDH. To assist the 
client device 302 to generate a client-side secret key, 
the server 370 sends a key reply signal 408 that com- 
prises the server public value. Similarly, based on the 
received server public value and self-generated client 
private value, the client module 332 generates a client- 
side secret key based on the same key agreement pro- 
tocol provided in LIBDH. As described above, the client- 
side secret key must be the same as the server-side se- 
cret key, referred to as shared secret key (SSK) under 
normal circumstances. To ensure that the secret keys 
are identical and that the public values have not been 
altered in transit in the open data network by the mid- 
dleman attacks, a two-step verification process is fol- 
lowed. 

[0038] The first step is to send a new SR 410 by the 
client module 332 to the server device 370. The compo- 
nents C-nonce and C-nonce Modified in the newSR 410 
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are now encrypted by the newly generated client-side 
secret key. Upon receiving the new SR 410, the server 
module 320 tries to decrypt Encry[C-nonce, C-nonce- 
Modified] using the newly generated server-side secret 
key. If the decryption is successful, that means the se- 
cret keys on both sides are identical with the assumption 
that there is no middle-man attacks when the public val- 
ues are exchanged in the data networks. The secret key 
can be regarded as the valid shared secret key (SSK) 
and is committed, in server's persistent storage. That 
SSK is subject to further verification as defined as the 
second step . If the decryption fails, that means the se- 
cret keys on both sides are not the same, which could 
result from the possible data corruption of public values 
when they are transmitted over the data networks such 
as Airnet 1 02. A new crypto- ignition process may be re- 
started by sending another request response 404 in- 
cluding the error message to the client device 302, 
which indicates that the crypto ignition process is failed 
and another new crypto ignition process can be restart- 
ed. 

[0039] The second step is to examine signatures re- 
sulted from both secret keys. A secret key is a 1 6 byte 
binary number. The first 8 bytes are used as data to be 
encrypted by the second 8 bytes as the encryption key 
according to a mutually agreed cipher, for example, the 
block cipher RC5 in the RCA engine, the encrypted re- 
sult is referred to as the signature of the secret key. The 
signature may take the form of, for example, FE63 AB- 
CD 47FA 3DA3. If the public values have not been al- 
tered, the secret keys on both sides will be the same, 
hence the signatures. The use ol signatures provides a 
means for direct verification between the client side and 
the server side. For example, the user of the client de- 
vice may call the operator of the service device to verify 
if there is a match between the two signatures respec- 
tively resulted from the client secret key and the server 
secret key. If the signatures are identical, it indicates that 
there was no middleman attack, otherwise the crypto- 
ignition process is considered failed. 
[0040] To reduce the air traffic, the step one verifica- 
tion process is piggybacked with a new session to be 
created. In other words, the verification process is start- 
ed by the client device 302 by sending a new session 
request to the server device 370. If the verification suc- 
ceeds, namely, the encryption keys on both sides are 
identical, the new session will be continued with a series 
of authentication between the client device 302 and the 
server device 370 th rough the session reply 41 2 and the 
complete message 414. A secure and authenticated 
communication session is thereby established. 
[0041] The code listing in the appended microfiche is 
one embodiment of the present invention. Source files 
SessionTxn.c and netsugp.c describe all detailed steps 
and procedures of the crypto-ignition process in the 
server device 370 and the client device 320 respectively. 
A function named KeyExchlnit() in the netsugp.c per- 
forms the initialization for the crypto- ignition process by 



starling KeyExchangeDoPhaseOneQ function which 
first allocates a memory area to perform the key ex- 
change protocol through DHInit() function. A random 
number is obtained from DevGetRandom() function and 
s is to be used in DHPhaseOneQ function as the client 
private value. DHPhaseOneO generates and the client 
public values for the client device 332. In netSetup- 
KeyExch() function, the public value is put into function 
KeyRequest PDU through SugpKeyRqstSetKeyDataQ 
10 function. The constructed KeyRequest PDU is then sent 
to the server through DevSendPDU() function in net- 
DoTxnQ function. 

[0042] The crypto-ignition process starts in the func- 
tion TsessionTxn::lgnrtion in SessionTxn.c when a 
KeyRequest PDU is received by the server module 320 
from the client device 302. The server device 302 is set 
by function to Clgnition to start the process, creates a 
proto-session, pulling out the corresponding record 321 
out of the database 328. The server device 370 then 
verifies if the client device 302 is registered or disabled 
temporarily, and if the crypto-ignition is allowed. If any 
one of those conditions are not met, the crypto-ignition 
process will be aborted and an error code is sent from 
the server device 370 to the client device 302. 
[0043] When all those conditions are satisfied, the 
server module 320 creates an instance object of the 
TkeyAgree, keyagree, for the client device 302 that 
sends the KeyRequest PDU. The server module 320 op- 
erates on the keyagree object with operations such as 
lnit(), PubKeyGen(), GetSSKey(), andlsWeakKey(). Init 
() operation initializes the calculation for the key agree- 
ment protocol; PubKeyGenQ generates the public value 
and the private value through the key agreement proto- 
col and the random number generator; PubKeyGen() is 
internally linked with a random number engine, from 
which the server private value is generated; GetSSKey 
() calculates the server-side secret key with inputs of the 
client public value in the KeyRequest PDU from the cli- 
ent device 302 and the private value of its own. 
IsWeakKeyO checks if the generated server-side secret 
key can be safely used as an encryption key. If not, the 
above process will be repeated until a good server-side 
secret key is found. Function CmaxKeyTries controls 
the iterations before the server module 320 gives 0 up 
and subsequently sends an error message to the client. 
Upon receiving the error message, the client device 302 
sends another KeyRequest PDU to repeat the whole 
process until a good server-side secret key is generated 
to the server's satisfaction in CmaxKeyTries. 
[0044] The server device 370 then delivers the server 
public value to the client device 302 in KeyReply PDU 
for the client device 302 to complete the crypto ignition 
process by using m_rAirlink-> Deliver() function. Mean- 
while the server device 370 saves the server-side secret 
key in m_pNewCipher and wait tor the client device 302 
to initiate the verification process that commits the serv- 
er-side secret key to the SSK that is then )loaded into 
the persistent database through a new session creation 
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request from the client device 302. 
[0045] In netsugp.c, namely the client side, KeyReply 
PDU is received through the function NetDataArrivedQ 
function, and is passed into netHandleKeyRply() func- 
tion. The server public value in KeyReply PDU from the 5 
server is extracted and is fed into KeyExchDoPhaseTwo 
() function to generate the client-side secret key. After 
the client-side secret key is successfully generated, the 
client module 332 saves it into its persistence storage 
and clears its needs for crypto- ignition request by calling io 
ClearNeeds(kKeyExch) function. To verify both secret 
keys generated respectively in the client device 302 and 
the server device 370, the client device 302 then makes 
a new session request to create a new session by using 
the newly generated client-side secret key to encrypt C- f 5 
nonce and C-nonceModified in the SessionRequest 
PDU which can be observed in the function netSetupS- 
ess() function. The SessionRequest PDU is sent from 
the client device 302 to the server device 370. 
[0046] In SessionTxn.C, when the SessionRequest 20 
PDU is received by the server device 370, the server 
module 320 calls TSessionTxn::Start() to process the 
request. As far as the crypto- ignition process is con- 
cerned, a successful decryption on the coming Session- 
Request PDU by using the newly generated server-side 25 
secret key will commit the server-side secret key to the 
SSK that is then loaded into its persistent database. In 
the same function, the server module 320 checks if there 
is a pending crypto- ignition process by checking if 
m_pNewCipher exists. If so, it is used to decrypt the 30 
SessionRequest PDU. If the decryption is successful, 
the server saves the server-side secret key as the 
shared secret key by using the functions m_rSession- 
>m_pSubscriber-> SetKeyQ and rrwSession- > 
m_pSubscriber-> ExchangeComplete(). The signature 35 
is also taken and saved at that point by using 
m_pNewCipher-> MakeSignatureQ function. This com- 
pletes the crypto-ignition process in the server 370. 
[0047] Referring now to Figures 5A and 5B, there are 
shown data flowcharts of the crypto- ignition process 40 
(CI P) respectively in the client device 302 and the server 
device 370. Both Figures 5A and 5B should be under- 
stood in conjunction with Figures 3 and 4. As described 
above, the crypto-ignition process may be started in 
several ways of which one is to initiate the process by 45 
manually requesting a new crypto-ignition process to be 
conducted between the client device 302 and the server 
device 370. A second way is from the error message in 
the session request response 404 sent by the server de- 
vice 370 due to, for example, complete failure of de- so 
crypting the SR 402, the expiration or mismatch of the 
SSKs on both sides. 

[0048] The client device starts the crypto-ignition 
process (CIP) at 502 in Figure 5A. At step 504, the client 
module generates the client private value followed by 55 
generating the client public value, the processes thereof 
have been described above. When the client public val- 
ue becomes available, the client module sends a key 



request signal 406 to the server module at step 506. The 
client device starts waiting for a key reply 408 from the 
server device at step 508. While waiting for the key reply 
408, the client device may receive signals other than the 
desired key reply 408 from the intended server device. 
If the received signals are not the desired key reply 408, 
they are discarded at step 510. To prevent the client de- 
vice to wait indefinitely, a time limit is placed upon the 
waiting, for example, 60 seconds. Within the time limit, 
the desired key reply 408 must be received otherwise 
an error message is displayed on the display screen of 
the client device at step 512 to inform the user thereof 
that the current crypto-ignition is aborted at step 514. 
[0049] Referring now to Figure 5B, upon receiving key 
request signal 406 at step 552 from a client device, the 
server module creates a server proto session at step 
554 for the client device with a session identifier, re- 
ferred to as session ID, to identify the session requested 
by the client device to be created with the server. A serv- 
er proto-session is a session entry marked as a proto 
status in a session table, which indicates that the ses- 
sion is not authenticated and is not able to conduct any 
transactions with the client. It is understood to those 
skilled in the art that the proto-session can be kept in 
the RAM of the server and there could be more than one 
proto-s ess ions if the server device is in communication 
with other client devices. If a proto- session already ex- 
ists for the particular client device, it is re-used. The in- 
formation in the received SR is saved in the proto-ses- 
sion. To ensure that the server module communicates 
with an authorized client device, the server device con- 
ducts a series of verifications. At 556, the server device 
first examines if the device ID in received SR 402 is valid 
by comparing the received ID with the device ID as- 
signed in the account. If the received device ID is valid, 
the server module further examines if the client device 
is enabled at 558. Sometimes a client device may have 
a valid device I D but the client device is disabled for cer- 
tain reasons. When the client device is recognized and 
authorized with the server device, the server module ex- 
amines if the crypto-ignition process is enabled by ex- 
amining the key state in the user account. As described, 
the key state is set to "Exchange" when the user account 
is newly established. The states that allow the crypto- 
ignition process are the "Exchange" and "Force", which 
considers the current crypto-ignition process is enabled; 
otherwise, it is not enabled. 

[0050] If any one of the verifications at steps 556, 558 
or 560, fails then the server module will send a device 
error at 562 to inform the client that the attempted CIP 
has been aborted. The server then removes the created 
proto session for this particular session at step 586 and 
aborts the CIP at step 590. 

[0051] When all the verifications at steps 556, 558 and 
560 succeed, the server module proceeds with gener- 
ating the server private value and the server public val- 
ue, the procedures of which have been described 
above. With the received client public value and the 
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server-self generated private value, the server module 
generates a server-side secret key according to a com- 
monly key agreement protocol at step 564. For security 
reasons, the server-side secret key generated at step 
526 is put through a key examination process at step s 
566. The key examination process is to ensure that the 
generated secret key has a sufficient random pattern 
and is not easily reproduced by the cryptanalysis. Some 
of the patterns that may be easily statistically detected 
are the keys with periodic O's and 1's, such as 10 
0101 01 01 01 a01 , which is easily subject to unauthorized 
duplication. These SSKs are considered weak and 
should be discarded and regenerated. At step 568, there 
is a counter to monitor the number of times a generated 
secret key has to be regenerated. If the counter is great- is 
er than a certain n umber, for example 10, the server de- 
vice gives up and then sends an error message to the 
client at 578, requesting the client to start the CIP all 
over again. If the generated secret or the regenerated 
secret key passes the key examination process at step 20 
566, the server at step 570 sends a key reply signal with 
the server public value to the client module and causes 
the client module to generate a client-side secret key. 
Similar to the client device, the server module starts 
waiting for a reply from the client device at step 572. Any 2s 
unwanted signals will be discarded at 574. If the server 
module waits for too long, the initially created proto-ses- 
sion will be removed at 586 and the current crypto-igni- 
tion process is aborted at 590. 

[0052] Referring back to Figure 5A, the client module 30 
is waiting for the key reply signal at step 508. The client 
module generates a client-side secret key at step 516 
upon receiving the key reply signal from the server de- 
vice. Thus, the client module relies upon the server to 
test for weak SSKs. TJie client module starts the similar 35 
key generating process, using the server public value 
and the client- self generated private value to generate 
the client-side secret key according to the commonly 
used key agreement protocol at 516. From the perspec- 
tive of the client device, the generated client-side secret 40 
key is assumed valid and the client module commits the 
generated client-side secret key to the SSK by loading 
it to its persistent memory or RAM. The client then initi- 
ates a new session request 410 with Encry[C-nonce, C- 
nonceModified] by the client generated SSK. *5 
[0053] Referring back to Figure 5B, when server re- 
ceives the new session request 410 at step 572, the 
server looks up the proto session entry in the proto ses- 
sion table and performs a series of the verification proc- 
ess using the device ID in the new session request 410 so 
at step 576. When the server module is ensured that the 
new session request 410 does come from the recog- 
nized and authorized client device, it checks if Encry[C- 
nonce, C -nonce Modified] is successfully decrypted by 
the current server-side secret key, if successful, it indi- ss 
cates that the server-side secret key is a SSK with the 
client device. The server module commits the server- 
side secret key to the SSK with the client device by load- 



ing it into a persistent memory in the server device at 
582. Otherwise, it checks if Encry[C -nonce, C-nonce- 
Modified] can be successfully decrypted by the old SSK, 
that indicates that the client device has failed in the cur- 
rent crypto-ignition process. Then, the current crypto- 
ignition process is silently aborted (without sending an 
error message to the client) at 590 and a new session 
is created with the old SSK. So the process preserves 
the existing old SSK in case the current crypto-ignition 
process fails. 

[0054] To provide a means for verifying the created 
SSKs, two signatures from the two SSKs are verified at 
592. This may be proceeded by a verbal verification be- 
tween the user of the client device and an operator of 
the server device. As described above, a signature at 
the client side can be generated when the client-side 
secret key is produced. S, similarly, a signature at the 
server side can be generated when the server-side se- 
cret key is produced. If the two signatures are not 
matched, the current crypto-ignition process is failed 
and no secure communication sessions can be estab- 
lished. If the verification is successful, the current cryp- 
to-ignition process succeeds at 594. It should be noted 
that the verbal verification is not a necessary part of the 
current invention and used in one embodiment to illus- 
trate that the means for verifying the SSKs by comparing 
the signatures resulted from the SSKs is provided. 
[0055] The present invention has been described in 
sufficient detail with a certain degree of particularity. It 
is understood to those skilled in the art that the present 
disclosure of embodiments has been made by way of 
example only and that numerous changes in the ar- 
rangement and combination of parts as well as steps 
may be resorted without departing from the spirit and 
scope of the invention as claimed. Accordingly, the 
scope of the present invention is defined by the append- 
ed claims rather than the forgoing description of one em- 
bodiment. 



Claims 

1. A method for establishing a secure communication 
channel between a client device and a server de- 
vice over a data network, said method comprising: 

generating a client private value in said client 
device; 

generating a client public value based upon 
said client private value in said client device; 
sending a key request message from said client 
device to said server device; said key request 
message comprising said client public value; 
receiving a server response to said key request 
message from said server device; and 
generating a client-side secret key with respect 
to said client private value and said server re- 
sponse and according to a key agreement pro- 
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tocol. 

2. The method of claim 1, wherein said server re- 
sponse comprises a server public value, said server 
public value is generated in said server with respect s 
to said client public value in said key request mes- 
sage received from said client device. 

3. The method of claim 2, wherein said method further 
comprising: 10 

conducting a verification process that ensures 
said client-side secret key and a server-side se- 
cret key are compatible; said server-side secret 
key generated in said server device with re- 1$ 
spect to a server private value and said client 
public value in said key request message and 
according to said key agreement protocol. 

4. The method of claim 3, wherein said conducting a 20 
verification process comprises: 

encrypting a message by said client-side secret 
key; and 

sending said encrypted message to said server 2s 
device over said data network 

5. The method of claim 4, wherein said conducting a 
verification process further comprises: 

30 

verifying that a client signature from said client- 
side secret key is matched to a server signature 
from said server-side secret key; and 
committing said client-side secret key and said 
server-side secret key to a pair of shared secret 35 
keys if said client signature and said server sig- 
nature are matched. 

6. The method of any one of claims 3 to 5, wherein 
said conducting a verification process comprises: *o 

initiating a session request by said client device 
to establish a communication session with said 
server device; wherein said session request 
comprises a device ID of said client device, an *s 
encrypted message by said client-side secret 
key according to a mutually accepted cipher; 
and 

receiving a session reply from said server de- 
vice after said encrypted message is success- so 
fully decrypted by said server-side secret key 

7. A method for establishing a secure communication 
channel between a client device and a server de- 
vice over a data network, said method comprising: 55 

receiving a key request message from said cli- 
ent device; said key request message compris- 
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ing an identifier identifying said client device 
and a client public value generated in said client 
device; 

creating a proto session in said server device 
for said client device; 

generating a server-side secret key from said 
received client public value and a server private 
value according to a key agreement protocol; 
sending a server response to said client device 
in response to said key request message; said 
server response comprising a server public val- 
ue; wherein both server private value and serv- 
er public value are provided in said server de- 
vice; and 

conducting a verification process that ensures 
said server-side secret key is compatible to a 
client-side secret key generated in said client 
device. 

8. The method of claim 7, wherein said identifier is a 
device identification of said client device; and said 
method further comprising: 

determining if said device identification is valid 
with respect to an account accessible to said 
server device; and 

determining if a crypto-ignition process has 
been enabled by examining a key state in said 
account. 

9. The method of claim 7 or 8, said method further 
comprising: 

verifying a strength of said server-side secret 
key; and 

regenerating said server-side secret key if said 
server-side secret key is determined to be 
weak. 

10. The method of any one of claims 7 to 9, wherein 
said conducting a verification process comprises: 

verifying that a client signature from said client- 
side secret key is matched to a server signature 
from said server-side secret key; and 
committing said client-side secret key and said 
server-side secret key to a pair of shared secret 
keys if said client signature and said server sig- 
nature are matched. 

11. The method of claim 10, wherein said committing 
said client-side secret key and said server-side se- 
cret key to a pair of shared secret keys comprises: 

decrypting an encrypted message from said cli- 
ent device by said server device using said 
server-side secret key. said encrypted mes- 
sage encrypted by said client-side secret key 
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according to a mutually accepted cipher; and 
loading said server-side secret key to said pro- 
to-session when said encrypted message is 
successfully decrypted by said server device. 
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(57) The present invention relates to a method for 
establishing a secure communication channel between 
thin devices (302, 304, 306) and a server computer (37) 
over an insecure data network (102). A pair of public 
values is exchanged between )the thin device and the 
server computer over the data network, with each side 
generating its own secret key from a self-generated pri- 
vate value along with the received counterpart's public 



value according to a commonly used key agreement 
protocol, such as the Diffie-Hellman key agreement pro- 
tocol. To ensure that the generated secret keys are iden- 
tical on both sides, a verification process is followed by 
exchanging a message encrypted by one of two gener- 
ated secret keys. The secret keys are proved to be iden- 
tical and secret when the encrypted message is suc- 
cessfully decrypted by the other secret key. 
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